Companies today are tasked with implementing solutions for many types of integration challenges within their respective enterprises. Many of these challenges involve issues of application integration (e.g., integration among and/or between software applications and/or other systems) and fall into common patterns.
For example, a first area relates to propagation of similar business objects from one system to multiple other systems, such as, for example, in an order status change or a product price change. A second area relates to synchronization of similar business objects between two or more systems to obtain a single view, such as, for example, a real-time synchronization of customer, product registration, product order, and product SKU information among several applications. This is the most common issue requiring an integration solution. In a one-way synchronization, there generally is one system (e.g., resource) that acts as a data source and one or more resources that are targets of the synchronization. In a two-way synchronization, every resource often is both a potential source and target of a synchronization. There generally is not a single resource that acts as the primary data resource. Thus, a change to any resource should be reflected in all other resources. A third area involves information joined from multiple sources into a common destination system, such as, for example, communicating pharmacy customer records and prescription transactions and website data into a central application and database.
Various tools have been provided that enable a user to design and deploy solutions that address these challenges using, for example, the publish-and-subscribe model or one of its variants. The publish-and-subscribe model is a specific type of message-based solution in which messages are exchanged anonymously through a message broker. Applications that produce information that needs to be shared make this information available in specific types of recognizable documents that they publish to the message broker. Applications that require information subscribe to the document types they need.
At run time, the message broker receives documents from publishers and then distributes the documents to subscribers. The subscribing application processes or performs work using the document and may or may not send a response to the publishing application.
In a typical system, an integration server or applications running on an integration server publish documents to a broker. The broker then routes the documents to subscribers located on other integration servers. The integration server and the broker share a fast, efficient process for exchanging documents across the entire system.
Although such techniques have been successful in providing solutions to the above-described challenge areas, further enhancements are still possible. For example, the integration server (IS) “Trigger Subsystem” provides a rich infrastructure for message processing (e.g., asynchronous message processing). However, this functionality is only available for messaging over a proprietary (e.g., broker) messaging protocol. Thus, users currently have to make a difficult design decision, choosing between either a feature-rich proprietary protocol, or a standards-based interoperable messaging protocol (e.g., JMS).
One approach to solving this problem has involved the use of a JMS adapter provided to an integration server. Thus, both a proprietary “trigger subsystem” (provided by the integration server for proprietary messaging) and a separate JMS adapter were provided to the integration server.
Unfortunately, this approach is somewhat incomplete. In particular, despite the availability of a JMS adapter for standards-based interoperable messaging, the “trigger subsystem” capabilities could not be fully used in connection with JMS. That is, users who want the extended capabilities of the “trigger subsystem” while using the JMS adapter would have to custom-implement those capabilities in their applications for every new application. This often imposes significant configuration and programming requirements and has led to a plethora of non-standardized implementations of the same and/or similar functionality. This problem is further exacerbated, as JMS is still in the process of being standardized for use in the in web-services context. In essence, this means that if capabilities comparable to those of the proprietary broker were required, they would have to be implemented in the application services layer time and time again. Even where such approaches have been implemented, they have not been standardized, e.g., because enterprises are different in terms of their organizations, processes, requirements, infrastructure, etc.
Thus, a problem remains in that there is not a single means to couple the current “trigger subsystem” and all of its capabilities with standards-based messaging (e.g., via JMS). Accordingly, there remains a tradeoff between a feature-rich proprietary protocol on the one hand, and a standards-based interoperable messaging protocol (e.g., JMS) on the other.
Thus, it will be appreciated that there is a need in the art for improved techniques for providing application integration solutions in one or more of the above-noted and/or other areas.
As described in detail below, one example technique for overcoming these and/or other problems relates to providing a messaging layer that provides a rich feature set for addressing application integration challenges that is accessible through both proprietary and open messaging constructs existing outside of the application layer. Such messaging constructs may be in the form of “triggers,” and such triggers may enable a publish-and-subscribe type solution to such application integration challenges in certain example embodiments. These triggers may be JMS triggers.
Another aspect relates to parallel subsystems being accessible through a common trigger subsystem provided as value-added layer above the respective trigger subsystems.
Still another aspect relates to substantially fully embedding JMS as a peer to the proprietary messaging protocol in the integration server trigger subsystem so that all or substantially all existing capabilities would be JMS-enabled.
A further aspect relates to the use of a messaging layer that enables JMS messaging without the use of a special adapter provided to an integration server. Furthermore, such a messaging layer may make it possible to avoid making any changes to the JMS trigger itself and/or may reduce the need for custom programming and/or implementation at the application service level in certain example cases.
Although these brokers are advantageous, further improvements are still possible. For example, it will be appreciated that the broker could be improved so as to offer an extensible load balancing feature. Indeed, the inventors of the instant application have taken note that customers have been requesting failover and load balancing features for their broker applications for the past several years.
Accordingly, one aspect of certain example embodiments relates to allowing brokers to implement client-side failover and load balancing functions. The load balancing functions of certain example embodiments may reside within the application space and also may be scalable.
Another aspect of certain example embodiments relates to enabling load balancing features work with a broker cluster. In this regard, publishers and subscribers may connect to a broker cluster, and the brokers in the broker cluster may share the message routing from publishers to subscribers.
Still another aspect of certain example embodiments relates to providing load balancing functions according to one or more policies, with those policies being “stackable” or “layerable” or “compound.”
Certain example embodiments relate to an application integration system. A publishing application is configured to generate and send a message. The message is sendable in accordance with a user-defined composite policy comprising at least first and second policy layers. First and second broker clusters are provided. Each broker cluster comprises a plurality of brokers, and each broker is configured to relay messages from the publishing application to at least one subscribing application. A composite cluster connection is associated with the publishing application. A plurality of cluster connections is associated with the composite cluster connection. The composite cluster connection is configured to route the message to at least one cluster connection in dependence on the first policy layer. Each cluster connection is configured to route the message to at least one broker in dependence on the second policy layer.
Certain example embodiments relate to a message routing method in an application integration system. A publishing application is provided. First and second broker clusters are provided. Each broker cluster comprises a plurality of brokers, and each broker is configured to relay messages from the publishing application to at least one subscribing application. A composite cluster connection is associated with the publishing application. A plurality of cluster connections is associated with the composite cluster connection. A message is generated by the publishing application. The message is sent from the publishing application to the broker cluster in accordance with a user-defined composite policy comprising at least first and second policy layers. The message is routed from the composite cluster connection to at least one cluster connection in dependence on the first policy layer. The messaging is routed from the at least one cluster to at least one broker in dependence on the second policy layer.
Certain example embodiments relate to a method of invoking a target service in an application integration system. First and second client systems are provided, and together they implement a publish/subscribe message exchange model. At least one broker cluster is provided, with the broker cluster including a plurality of broker servers. A message is generated by the first client system, with the message being a trigger for invoking the target service on the second client system. The message is routed from the first client system to at least one broker server in at least one broker cluster to the second client system based on a policy defined by the first client system. The message is received at the second client system. The target service is invoked via the second client system.
These aspects and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.